esp@cenet document view 



Page 1 of 1 



System and method for managing attributes in an object-oriented 
environment 



Publication number: EP1 054332 

Publication date: 2000-1 1 -22 

Inventor: CAUBIT PIERRE (FR) 

Applicant: BULL SA (FR) 
Classification: 

- international: G06F17/30; G06F17/30; (IPC1-7): G06F17/30 

- European: Q06F1 7/30S8T; G06F1 7/30B 
Application number: EP20000401 375 2000051 9 
Priority number(s): FR1 9990006353 1 999051 9 



Also published as: 

S FR2793906 (A1) 

Cited documents: 

Q XP002128177 
1 XP000594128 
J XP002131457 



Report a data error here 



Abstract of EP1 054332 

Database (4) comprises objects (5) with standard attributes (6) with the database able to be interrogated 
by an application, user, etc. The objects (5) are characterized by specific attributes (20) with the same 
external structure as standard attributes the internal structure of which enables the administration and 
definition of components (21) independent of the database. 
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(54) Systeme et procede de gestion d'attributs dans un environnement oriente objet 



(57) La presente invention concerne un procede de 
gestion d'une base de donnees (4) ou annuaire ou equi- 
valent comportant des objets (5) caracterises par des 
attributs standards (6), la base etant apte a etre interro- 
gee par une application, un utilisateur ou autre, appele 
entite, consistant a caracteriser les objets (5) par des 



attributs specifiques (20) dits attributs opaques (20), 
presentant la meme structure externe que les attributs 
standards (6) et dont la structure interne permet de de- 
finir et administrer des composants (21 ) de maniere in- 
dependante a la base (4). 

La presente invention concerne egalement le sys- 
teme mettant en oeuvre ledit procede. 
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Description 

[0001] La presente invention concerne le domaine 
des bases de donnees dans un environnement d'ordi- 
nateur oriente objet. 

L'art anterieur 

[0002] Une base de donnees, un annuaire ou equiva- 
lent organise de maniere coherente des objets partages 
par des utilisaleurs ou des applications. 
[0003] Un objet est une abstraction d'une donnee du 
monde reel. L'objet est caracterise par une identite, un 
etat et un comportement. L'identite d'un objet est repre- 
sents par un identifiant unique et invariant qui permet 
de referencer l'objet independamment des autres ob- 
jets. Les valeurs de I 1 etat d'un objet sont donnees par 
des attributs. Le comportement d'un objet est defini par 
un ensemble d'operations applicables a l'objet. Les ob- 
jets similaires sont groupes en classe. Une classe decrit 
la structure et le comportement commun d'objets. Les 
objets et les attributs sont definis dans un schema de la 
base. 

[0004] Dans les bases de donnees actuelles, tous les 
attributs sont declares dans le schema de la base. 
[0005] Or, la complexity et revolution rapide des in- 
formations contenues dans une base de donnees sou- 
levent de nombreux problemes : 
[0006] La description du schema de la base est fre- 
quemment modifiee ce qui necessite une gestion per- 
manente et couteuse de la base et enframe une gene 
pour les utilisateurs et administrateurs. 
[0007] Des objets de versions differentes sont sus- 
ceptibles d'etre geres par une meme base. Le probleme 
de gestion de versions se complique avec la replication 
des bases dans un environnement distribue et plus par- 
ticulierement lorsque les differentes versions se situent 
sur des machines differentes. 

[0008] L'utilisateur a souvent besoin d'acceder rapi- 
dement a une suite d'attributs d'un objet donne. La base 
est sollicitee pour la recherche de chacun des attributs. 
II en resulte un encombrement dans la consultation de 
la base, une lenteur dans I'obtention d'une reponse a 
une interrogation. 

[0009] II serait avantageux que des composants de 
types differents (chafne de caracteres, entier, boo- 
leen...) soient stockes dans un meme attribut, ce qui 
n'est pas realisable avec les systemes actuels connus. 
[001 0] L'origine, I'integrite ou la confidentiality des in- 
formations stockees dans la base ne sont garanties 
qu'apres application de techniques diverses sur les at- 
tributs, techniques rapportees, lourdes et couteuses. 
[0011] Un butde la presente invention est de permet- 
tre de modifierfacilement et rapidement les informations 
associees a une classe d'objets. 
[0012] Un autre but de la presente invention est d'ac- 
ceder rapidement a une suite d'attributs. 
[0013] Un autre but est d'integrer des composants de 



differents types dans un meme attribut. 
[0014] Un autre but de la presente invention est d'ad- 
ministrer la cohabitation d'objets de versions differentes 
dans une meme base ou des bases repliquees. 
5 [0015] Un autre but est de garantir l'origine, I'integrite 
et la confidentiality de I'information sans recours a des 
techniques rapportees. 

Resume de I'invention 

10 

[0016] Dans ce contexte, la presente invention propo- 
se un procede de gestion d'une base de donnees ou 
annuaire ou equivalent comportant des objets caracte- 
rises par des attributs standards, la base etant apte a 

is etre interrogee par une application, un utilisateur ou 
autre appele entite, caracterise en ce qu'il consiste a 
caracteriser les objets par des attributs specifiques dits 
attributs opaques, presentant la meme structure exter- 
ne que les attributs standards et dont la structure interne 

20 permet de definir et administrer des composants de ma- 
niere independante a la base. 
[0017] La presente invention concerne le systeme in- 
formatique de mise en oeuvre du procede selon I'inven- 
tion. 

25 [0018] La presente invention se rapporte egalement 
a un systeme informatique comprenant au moins une 
machine munie d'une base de donnees ou annuaire ou 
equivalent susceptible d'etre interrogee par une appli- 
cation, un utilisateur ou autre, appele entile, caracterise 

30 en ce qu'il comprend une interface de programmation 
au niveau applicatif API entre la base et Pentite compre- 
nant des fonctions d'acces a la base et des fonctions de 
gestion d'attributs standards et/ou d'attributs opaques. 

35 Presentation des figures 

[0019] D'autres caracteristiques et avantages de I'in- 
vention apparaitront a la lumiere de la description qui 
suit, donnee a titre d'exemple illustratif et non limitatif 
40 de la presente invention, en reference aux dessins an- 
nexes dans lesquels: 

• la figure 1 est une vue schematique du systeme se- 
lon la presente invention ; 

45 « la figure 2 represente de maniere schematique la 
structure d'un attribut opaque du systeme selon la 
figure 1 ; 

• la figure 3 represente de maniere schematique des 
etapes du procede selon la presente invention. 

50 

Description d'une forme de realisation de I'inven- 
tion 

[0020] Comme represente sur la figure 1 , la presente 
55 invention se rapporte a un systeme d'information 1 dont 
I'environnement est de type oriente objet. Le systeme 1 
comporte au moins une machine 2. Le terme « machine 
» est utilise dans un sens general pour designer tout 
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type d'ordinateurs ou equivalents. 
[0021] Le systeme 1 peut etre un systeme dont I'en- 
vironnement est de type distribue ou local. Dans la for- 
me de realisation illustree sur la figure 1 , le systeme 1 
de type distribue comprend trois machines 2a, 2b, 2c, 
appelees respectivement machine 2a annuaire, machi- 
ne 2b de stockage, machine 2c d'administration. Seuls 
les composants des machines 2 du systeme 1 caracte- 
ristiques de la presente invention seront decrits, les 
autres composants etant connus de I'homme du metier. 
Les machines 2 sont reliees entre elles au travers d'un 
reseau 3 ; dans la forme de realisation de la figure 1 , la 
machine 2a est reliee aux machines 2b et 2c par le re- 
seau 3. 

[0022] Le systeme 1 comporte une base de donnees 
ou un annuaire 4 ou equivalent installe sur la machine 
2a annuaire, Dans la description qui suit, il sera fait re- 
ference a I'annuaire 4. L'annuaire 4 contient des objets 
5 caracterises par des attributs de type connu dits attri- 
buts standards 6. Dans I'exemple illustre sur la figure 1 , 
les informations sont structures en objets 5 integres 
dans l'annuaire 4 suivant le modele X500 connu ; la ma- 
chine 2a annuaire communique avec les machines 2b 
de stockage et 2c d'administration au travers d'une in- 
terface 7 LDAR 

[0023] Des utilisateurs ou des applications diverses 
ou autres, appeles ci-apres entites 8 sont susceptibles 
d'interroger l'annuaire 4 directement sur la machine 2a 
annuaire I'hebergeant ou a partir d'autres machines 2b, 
2c. Dans I'exemple illustre sur la figure 1, une applica- 
tion 8 est installee sur la machine 2c d'administration et 
travaille avec les donnees de l'annuaire 4. Selon une 
forme de realisation particuiiere, ('application 8 est mu- 
nie d'une interface graphique 9. 
[0024] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2b de stockage sur la figure 1 ) comprend un 
compilateur 10 de description et des moyens de stoc- 
kage 11 d'au moins un fichier 12 source de description. 
[0025] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2c d'administration sur la figure 1 ) comprend 
une interface de programmation au niveau applicatif, 
appelee couramment interface AP1 1 3 munie d'au moins 
une fonction 14 de gestion et d'au moins une fonction 
15 d'acces a l'annuaire 4, des moyens 16 de memori- 
sation d'une structure 17 de communication entre I'in- 
terface AP1 1 3 et I'entite 8, une memoire tampon 18, un 
module de securite 19. 

[0026] Le procede selon la presente invention consis- 
te a caracteriser les objets 5 par des attributs specifi- 
ques 20 dits attributs opaques 20, presentant la meme 
structure externe que les attributs standards 6 et dont 
la structure interne permet de definir et administrer des 
composants 21 de maniere independante a l'annuaire 4. 
[0027] Les structures des attributs standards 6 sont 
de trois types : de type texte directement lisible par In- 
terface 7, de type binaire representant une unique infor- 
mation d'un type determine qui n'est pas directement 
lisible par I'interface 7, detype specialise requerantdes 



controles de syntaxe. 

[0028] Le terme « structure externe » signifie que la 
structure de I'attribut opaque 20 telle que vue par I'an- 
nuaire 4 et I'interface 7 est identique a la structure d'un 

s attribut standard 6. Pour I'annuaire 4 et I'interface 7, les 
attributs opaques 20 presentent une structure externe 
de type binaire. Un attribut opaque 20 est considere par 
I'interface 7 entre I'entite 8 et I'annuaire 4 comme un at- 
tribut standard 6. 

10 [0029] L'attribut opaque 20 est comparable a un 
container : des composants 21 sont introduits dans le 
container. Les composants 21 sont independants de la 
technologie ou de I'organisation de l'annuaire 4. II est 
possible de rajouter des composants 21 dans l'attribut 

'5 opaque 20 sans modifier le schema de l'annuaire 4. Les 
composants 21 introduits dans l'attribut opaque 20 peu- 
vent etre de types varies. 

[0030] L'objet 5 est identifie de maniere unique dans 
l'annuaire 4: les attributs opaques 20 sont crees a cha- 

20 que besoin specifique d'une entite 8. Le contenu des 
attributs opaques 20 depend de I'entite 8 contrairement 
a celui des attributs standards 6 dependant de l'annuai- 
re 4 et de son schema de base. 
[0031] L'attribut opaque, de type binaire pour I'inter- 

25 face 7, presente une structure interne determinee sus- 
ceptible d'etre exploitee par I'interface AP1 13, structure 
dans laquelle divers types de composants 21 sont clas- 
ses. 

[0032] Selon une forme de realisation de I'invention 
30 illustree sur la figure 2, la structure interne de l'attribut 
opaque 20 est constitute de trois parties : 

• un en-tete 22 ; 

• une table 23 de caracteristiques des composants 
35 21 ; 

• un ensemble 24 de valeurs des composants 21 . 

[0033] La structure interne de l'attribut opaque est 
predefine de maniere a retrouver les composants 21 
40 dans les informations de type binaire de l'attribut opa- 
que 20 comme vu plus haut. 

[0034] L'en-tete 22 fournit des informations generates 
sur l'attribut opaque 20 concerne telles que : 

45 • une version du formalisme de la structure utilisee 
pour I'attribut opaque 20 et pour les composants 21 
contenus dans l'attribut opaque 20 concerne. La 
version assure une evolution de la structure de l'ob- 
jet et permet la compatibility montante et descen- 

so dante des structures comme il sera vu plus loin ; 

• une longueur en octets des donnees suivantes de 
l'en-tete (informations de securite, date de derniere 
mise a jour ...) de maniere a retrouver la table 23 
dans les donnees binaires de l'attribut, comme vu 

55 plus haut ; 

• des informations de securite assurant I'integrite, 
I'origine et la confidentialite des composants conte- 
nus dans I'attribut opaque. Les attributs sont prote- 
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ges d'alterations ou d'extractions rton souhaitees, 
Des services de signature et/ou de chiffrement sonl 
susceptibles d'etre mis en oeuvre. Les informations 
de securite permettent la signature de I'attribut de 
maniere globale, ce qui ameliore les performances. 
Les informations de securite sont par exemple In- 
dication d'une signature souhaitee ou non pour I'at- 
tribut, I'indication d'un chiffrement souhaite pour 
tous les composants de I'attribut ou seulement cer- 
tains d'entre eux ou encore non souhaite, la force 
desalgorithmes utilises, les algorithmes utilises (si- 
gnature DSA, RSA... ; chiffrement DES, IDEA...), 
I'etat des composants de I'attribut dans I'ensemble 
24 (signe ou non, chiffre ou non), la cle utilisee, la 
valeur de la signature,... 

• une date de derniere mise a jour de I'attribut opaque 
20 concerne ; ... 

[0035] La table 23 indique les caracteristiques des 
composants 21 contenus dans I'attribut opaque 20 en 
question. Les caracteristiques des composants 21 per- 
mettent notamment de retrouver un composant 21 de- 
termine dans I'ensemble 24 des composants 21 . La ta- 
ble 23 comprend : 

• I'identifiant d'un composant 21 sous la forme par 
exemple d'un numero d'identification ; 

• un type de codage du composant 21 concerne. Le 
type de codage decrit le mode de representation 
des composants 21 dans I'attribut opaque 20. I'at- 
tribut opaque est susceptible de contenir des com- 
posants de types varies. Le type permet le contrfile 
du stockage des composants 21 dans I'attribut opa- 
que 20, I'organisation des composants 21 en liste ; 

• des informations complementaires de codage com- 
me par exemple des informations concernant le ty- 
pe multimedia ; 

• une longueur utile de valeur du composant 21 con- 
cerne exprimee en octets ; ... 

[0036] Les composants 21 sont stockes dans I'en- 
semble 24 les uns a la suite des autres dans I'ordre dans 
lequel ils ont ete cites dans la table 23. L'identifiant et 
la longueur utile indiques dans la table 23 permettent 
de retrouver un composant 21 determine dans I'ensem- 
ble 24. 

[0037] L'attribut opaque 20 permet de regrouper des 
composants 21 de types differents et de permettre 
I'ajout, la modification ou la suppression d'un attribut 6, 
20 et/ou d'un composant 21 sans intervenir sur le sche- 
ma de I'annuaire 4. 

[0038] Selon une forme de realisation, les types de 
codage determines dans la table 23 se divisent en trois 
categories : les types simples, les types multimedia, les 
types constructeurs. 

[0039] Les types simples comprennent le type texte 
(« TEXT » en annexe) qui correspond a une chaTne de 
caracteres (texte quelconque), le type entierde valeur 



binaire, letype numerique (caracteres numeriquesde 0 
a 9), le type bit qui correspond a un champ d'octets, le 
type booleen (valeur vrai ou faux), le type enumere dont 
la valeur est associee a une constante, le type secret 
(texte special de type chiffre et de longueur quelcon- 
que), le type date/heure (format de date/heure etabli). 
[0040] Les types multimedia comportent le type ima- 
ge, le type son et le type video. 
[0041] Les types constructeurs introduisent et delimi- 
tent des structures telles que des listes. Le type liste (« 
LIST » en annexe) represente une liste de n occurren- 
ces d'une structure, le nombre maximum d'occurrences 
etant fixe. Le type fin de liste (« END » en annexe) clot 
la description d'une liste. Les types constructeurs auto- 
risent I'imbrication des listes; n niveaux d'imbrication 
sont possibles. Des regies d'utilisation accompagnent 
les types constructeurs. 

[0042] Tout autre type est susceptible d'etre utilise. 
[0043] Les fonctions 15 d'acces permettent I'acces 
auxattributs6, 20 de I'annuaire 4. Les fonctions 15 d'ac- 
ces permettent d'extraire, d'introduire, de modifier ou de 
supprimerdes attributs dans I'annuaire 4. Les fonctions 
15 mettent les attributs extraits de I'annuaire 4 a la dis- 
position des fonctions 14 de gestion dans la memoire 
tampon 18. Les fonctions 14 de gestion creent, modi- 
fient, suppriment des attributs et/ou des composants et 
transmettent le resultat des operations aux fonctions 15 
d'acces par I'intermediaire de la memoire tampon 18: 
les fonctions 15 d'acces introduisent les attributs et/ou 
composants crees ou modifies par les fonctions 14 dans 
I'annuaire 4, ou encore suppriment de I'annuaire 4 les 
attributs et/ou composants supprimes par les fonctions 
14 de gestion. 

[0044] Les fonctions 14 de gestion sont prevues pour 
I'exploitation des attributs opaques 20 de maniere inde- 
pendante a I'annuaire 4. 

[0045] Les fonctions 1 4 de gestion permettent d'intro- 
duire ou de supprimer des attributs standards 6 dans 
des objets 5, des composants 21 dans des attributs opa- 
ques 20 ou des attributs opaques 20 dans des objets, 
de lire ou modifier des attributs standards 6 ou des com- 
posants 21 des attributs opaques 20, en s'appuyant si 
necessaire sur une description 25 formelle compilee et 
stockee dans I'annuaire 4. Les fonctions 14 de gestion 
sont susceptibles de lire les composants 21 des attributs 
opaques 20 sans faire appel a la description 25 corres- 
pondante: les fonctions 14 de gestion doivent alors con- 
naitre l'identifiant du composant recherche (l'identifiant 
d'un attribut opaque est donne par la table 23 dudit at- 
tribut). L'attribut opaque contient le minimum d'informa- 
tions permettant aux fonctions de gestion 14 de lire les 
composants qu'il contient sans informations supple- 
mentaires. II est a noter que la lecture est I'operation la 
plus frequente statistiquement. Pour toute autre opera- 
tion telle la creation, la modification ou la suppression 
d'un attribut 6, 20 ou d'un composant 21 , la fonction 14 
de gestion requiert les informations de la description 25 
compilee. Lors d'operations de mise a jour (creation, 
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modification ou suppression), des controles sont neces- 
saires tels que des controles sur les longueurs, les ty- 
pes, les masques, les caracteres obligatoires... : les 
controles s'appuient sur les informations comprises 
dans les descriptions 25 compilees. 
[0046] II est a noter que les informations contenues 
dans les descriptions 25 pourraient, selon une forme de 
realisation de I'invention, etre comprises dans les attri- 
buts opaques 20. Les descriptions 25 compilees ame- 
liorent les performances du systeme 1. 
[0047] La description 25 de I'attribut opaque 20 est 
issue des fichiers source 12. Un fichier source 12 est 
reserve pour chaque description 25 et pour chaque ver- 
sion de la description 25. La compilation de la descrip- 
tion 25 s'effectue a partir des fichiers source 12 au 
moyen du compilateur 10. La compilation ameliore les 
performances de traitement, 

[0048] La description 25 compilee apporte a I'entite 8 
des informations relatives a un attribut opaque donne 
sans que I'entite ait a solliciter I'annuaire 4: le fichier 
source 12 contient des informations telles que le libelle 
externe de saisie du champ attribut ou composant « LBL 
» comme il sera vu plus loin, assurant une mise en forme 
automatique des formulaires de saisie de I'interface gra- 
phique 9 de I'entite 8: I'interface 9 est generee automa- 
tiquement sans avoir recours aux attributs stockes dans 
I'annuaire 4. La meme description 25 est utilisee pour 
la saisie de donnees exterieures au systeme 1 et la ges- 
tion de donnees appartenant a I'annuaire 4, ce qui as- 
sure une coherence dans la gestion des informations. 
[0049] Dans la forme de realisation des figures 1 et 3, 
les fichiers source 12 sont enregistres dans la machine 
2b de stockage. Le compilateur 10 de la machine 2b 
transforme le fichier source contenu dans les moyens 
de stockage 1 1 en une description 25 compilee stockee 
dans I'annuaire 4 de la machine 2a annuaire. La des- 
cription compilee liee a un objet 5 donne est stockee par 
exemple (figure 1) dans un objet 26 special. Le fichier 
compile beneficie des capacites de distribution des 
technologies d'annuaires. 

[0050] La description 25 compilee permet une evolu- 
tion en douceur du contenu des objets. Selon un exem- 
ple de forme de realisation, la description 25 comporte, 
comme il sera vu plus loin, le numero de version du con- 
tenu de I'objet 5 concerne : revolution de structure des 
objets 5 est geree a I'aide de numeros croissants de ver- 
sion. 

[0051] La gestion des versions est rendue souple et 
efficace. L'annuaire 4 peut evoluer sans cesse sans re- 
mettre en cause les objets existants et le schema de 
I'annuaire. La gestion des versions est assuree par les 
fonctions 14 de gestion lors de la creation ou suppres- 
sion d'objets 5 dans I'annuaire 4. 
[0052] Selon un exemple de realisation de la gestion 
des versions, il est prevu une compatibilite montante en- 
tre la description 25 d'un objet 5 et I'objet 5 effectif exis- 
tant (objet 5 de version V et description 25 de version 
V+n): 



[0053] Dans ce cas, afin d'assurer une totale compa- 
tibilite, c'est a dire une evolution de la structure des ob- 
jets 5 sans remettre en cause les objets existants, les 
regies suivantes sont appliquees dans les fonctions de 
5 gestion 1 4: 

Si un nouveau composant 21 apparaTt dans la des- 
cription 25, il est visible pour I'entite 8 et indique 
comme absent dans I'objet 5 courant mais ajoute 
to en mise a jour par la fonction de gestion 14 
concernee ; 

Si un composant 21 disparaTt de la description 25, 
il n'est plus visible pour I'entite 8 et est supprime de 
I'objet 5 a la mise a jour par la fonction de gestion 
16 14 concernee. 

[0054] II est egalement prevu une compatibilite des- 
cendante entre la description d'un objet et I'objet effectif 
existant (objet de version V et description de version V- 
n): 

[0055] Cette situation intervient dans des periodes 
transitoires de deploiement d'une nouvelle version de 
description d'objet, et de differences dues a la replica- 
tion des objets. 

[0056] Dans ce cas, une compatibilite minimum est 
assuree, permettant un fonctionnement transitoire, en 
attendant la mise a niveau de la description. 
[0057] Les regies suivantes sont appliquees : 

Si un composant 21 est present dans la description 
25 mais ne Test plus dans I'objet 5, le composant 
21 est considere comme absent de la description ; 
Si un composant est absent de la description mais 
present dans I'objet, il est considere comme present 
dans la description, accessible dans I'annuaire 4 au 
moyen de I'identifiant mais pas du nom interne qui 
n'est defini que dans la description. 

[0058] Les modifications a apporter au schema de 
I'annuaire 4 sont limitees : les evolutions sont deportees 
hors de I'annuaire 4. 

[0059] Dans la forme de realisation de la figure 1 , les 
attributs d'une classe d'objets 5 sont regroupes en 
items. Une classe d'objets peut contenir plusieurs items. 
Dans la forme de realisation decrite, un item est cons- 
titue d'au moins un attribut standard 6 et/ou d'un seul 
attribut opaque 20. Un attribut standard 6 ou un compo- 
sant 21 dans un item est appele dans ce qui suit un ele- 
ment de I'item. 

[0060] D'autres items sont susceptibles d'etre crees. 
[0061] Les descriptions 25 sont de deux types : 

• les descriptions 25a d'items ; 

• les descriptions 25b d'attributs. 

[0062] L'annexe 1 montre un exemple de description 
25 d'items et d'attributs. 

[0063] La description 25a d'items est referenced sous 
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la forme <Classe> - <ltem>, <Classe> represente la 
classe de I'objet 5 concerne, <ltem> I'item concerne (en- 
semble de composants d'un attribut opaque ou ensem- 
ble d'attributs standards dans ladite classe d'objets en 
question). Les items cites sont declares au prealable 
comme appartenant a la classe d'objets correspondante 
dans I'annuaire 4. Un fichier source 12 peut comporter 
une description d'items et une suite de descriptions d'at- 
tributs correspondants. 

[0064] La description 25 d'items comprend les infor- 
mations suivantes : 

• la classe de I'objet concerne, appelee « CLASS ». 
Les classes sont identifies par des mots cles re- 
serves. 

• les items declares dans un objet qui dependent de 
la classe de I'objet en question, appeles « ITEM ». 
Une classe d'objets est constitute de plusieurs 
items. Pour chaque classe, la liste des items qu'il 
doit/peut contenir est definie. A chaque type d'item 
est associe un identifiant unique. Dans la forme de 
realisation decrite, les identifiants sont : 

« BASE »: attributs standards 6 ; 
- « XXX » (tout terme different du terme BASE 
utilise pour les attributs standards) : attributs 
opaques 20. 

• la version de la description de I'item, appelee « 
VERSION ». Cette information est tres importante : 
elle assure une evolution compatible de la descrip- 
tion des items. 

• la liste des langues a utiliser, appelee « LANGUA- 
GES » telles que par exemple la langue utilisee 
pour les libelles d'attributs, ... ; une description re- 
quiert au moins une langue. Si une des langues 
n'est pas fournie explicitement pour un attribut, on 
prend par defaut la premiere langue definie dans la 
description pour Pattribut en question. 

[0065] La description 25 d'items peut egalement com- 
prendre des informations de securite optionnelles. Les 
informations sont dites optionnelles car elles impliquent 
une option par defaut en cas d'absence. Les informa- 
tions de securite sont definies dans I'en-tete 22 de Pat- 
tribut opaque 20 et/ou dans la description 25a d'items 
selon les besoins (options de securite generales et/ou 
pour seulement certains attributs). La protection des at- 
tributs opaques 20 s'effectue par chiffrement et/ou si- 
gnature. Par defaut, par exemple, les attributs opaques 
ne sont ni signes ni chiffres. Les parametres optionnels 
de la description 25a autorisent la modification des va- 
leurs de protection par defaut. 
[0066] Selon une forme de realisation, les parametres 
optionnels sont : 



• la signature de I'attribut en question ; 

• le chiffrement de I'attribut concerne ; dans le cas 
d'un chiffrement requis, les composants 21 de type 
secret ne sont pas chiffres individuellement. 

s • le niveau de chiffrement pour I'attribut en question. 

[0067] La description 25b d'attributs permet : 

• d'identifier chaque element de I'objet concerne par 
10 un nom interne et un identifiant, d'indiquer la cor- 
respondence entre le nom interne et I'identifiant 
pour un element donne ; 

• de definir les types des elements de I'objet 
concerne ; 

?s • de fournir des informations utilisables par les fonc- 
tions de gestion 1 4 des elements 21 ou directement 
par I'entite 8 (interface graphique 9) telles que : 

un libelle(s) du champ de saisie de I'element ; 
20 - une indication du statutobligatoireouoptionnel 
de I'element ; 

une taille minimum / maximum ; 
des contraintes sur I'element ; 
des informations complementaires sur I'ele- 
25 ment. 

[0068] La description comprend : 

• le nom interne de I'element concerne, appele « ATT 
30 ». Le nom interne permet de nommer simplement 

un element (attribut standard 6 /composant 21 d'un 
attribut opaque 20). II sert de reference pour la ges- 
tion ulterieure des descriptions d'items et pour ('ad- 
ministration de I'annuaire 4. Le nom interne est in- 
35 dependant du nom defini dans le schema de I'an- 
nuaire 4. Le nom interne identifie chaque element ; 
il est unique pour un objet 5 donne. Selon un exem- 
ple illustratif, le nom est donne sur 12 caracteres 
maximum. Le nom doit commencer sur le premier 
40 caractere de la ligne ; 

• I'identifiant, appele I'OID. L'identifiant identifie cha- 
que element; il est unique pour un item donne. 
L'identifiant est independant de I'identification dans 

45 I'annuaire 4. 

• le nom de I'element dans I'annuaire 4 utilise par Pin- 
terface 7 et obligatoire dans la description des at- 
tributs 6 standards, appele « XNM ». II est code par 

50 exemple sur 36 caracteres maximum ; 

• I'indication de I'etat de I'element au niveau de Fen- 
lite 8, appele « HID ». L'etatde I'element peut pren- 
dre lesvaleurs caches ou visibles. L'HID est declare 

55 avant les options qui suivent ; 

• le libelle externe de saisie du champ element tel que 
presents au niveau de I'entite 8, appele « LBL » ; 
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• le type de codage de I'element parmi ceux enonces 
precedemment, appele « TYP ». 

[0069] D'autres options sont susceptibles d'etre utili- 
ses telles que par exemple des options qui sont tone- s 
tion du type de codage de I'element. Quelques exem- 
ples sont donnes ci-apres permettant de comprendre 
Pexemple de fichiers source donne en annexe. 

• I'option « MDT » determine le statut obligatoire ou 10 

optionnel de I'element ; 

• I'option « RNG » represente la plage de longueur 
(chainedecaracteres, numerique, secret) oudeva- 
leur (entier), ou le nombre d'occurrences minimal et is 
maximal (type constructeur). 

• I'option « SZF » definit la taille du champ de saisie 
pour Pinterface graphique 9 de I'entite 8. 

• « CAS » definit la casse pour les types chaTnes de 
caracteres ; 

« FREE », la casse est respectee ; 
« UP », les majuscules sont forcees ; 
« LOW », les minuscules sont forcees. 

[0070] Les informations donnees par la description 
telles que I'option SZF par exemple permettent la mise 
en forme automatique (sans avoir recours a des modu- 
les supplementaires) des formulaires de saisie de I'in- 
terface graphique. 

[0071] Des options sont a prevoir egalement par 
exemple pour les types multimedia tels que : 

• I'option « PLD » indiquant le prechargement auto- 
matique des types multimedias dans la structure. 

• I'option « ALG » qui est un identifiant d'algorithme. 

[0072] Les identifiants d'algorithme pour le type ima- 
ge sont par exemple : 



0 


GIF 


1 


JPG 


2 


TIF (fractales) 


3 


Ondelettes 



Des identifiants sont egalement determines pour les ty- 
pes sons et video. 

[0073] La manipulation des elements s'effectue a 
I'aide des fonctions de gestion 14 en precisant Pit em. 
L'item doit etre precise a I'appel afin que les fonctions 
determined la structure concernee par I'operation a ef- 
fectuer. 

[0074] Les fonctions de gestion 1 4 permettent de ma- 
nipuler (creer, lire, modifier, supprimer, afficher) les don- 
nees suivantes : 



attributs standards des objets de I'annuaire 4 ; 
attributs opaques des objets de I'annuaire 4 et com- 
posants 21 de ces attributs ; 
- composants de securite de base integres dans des 
attributs des objets 5... 

[0075] Les elements manipules par les entites 8 sont 
controles, filtres par les fonctions 14 de gestion. 
[0076] Si la f onction de gestion 1 4 appelee necessite 
les descriptions 25a et b compilees de I'objet, lesdites 
descriptions sont chargees automatiquement par la 
fonction de gestion en question. Selon une forme de 
realisation particuliere de realisation, les descriptions 
compilees sont chargees dans la memoire tampon 18. 
Les fonctions de gestion 14 puisent dans les descrip- 
tions compilees les informations necessaires aux ope- 
rations qu'elles doivent effectuer. Les fonctions de ges- 
tion 1 4s'appuient sur la description 25ad'item pour con- 
naitre la classe d'objet et l'item concernes. 
[0077] Les fonctions de gestion dans la forme de rea- 
lisation decrite sont les suivantes : 



une fonction d'initialisation d'objets InitObj : I'appel 
a cette fonction permet d'initialiser la structure d'un 
25 nouvel objet ainsi que la structure d'attributs 6,20 
de I'objet cree de maniere a pouvoir y inserer des 
attributs standards 6 ou des composants 21 . L'objet 
5 est defini a I'appel de la fonction d'initialisation en 
precisant la classe de I'objet, l'item correspondant. 

30 

une fonction de rangement PutElem : la fonction de 
rangement realise la creation ou mise a jour d'un 
attribut 6,20 ou d'un composant 21 d'un attribut opa- 
que 20. A I'appel de la fonction de rangement sont 
35 precises la version, la classe, I'identifiant ou le nom 
de I'element, I'occurrence en cas de liste, la lon- 
gueur utile dans le cas de types bit ou secret, le type 
de codage de I'element. La fonction de rangement 
actualise pour chaque objet traite une liste des at- 
40 tributs modifiees afin d'optimiser la mise a jour. 

une fonction de lecture GetElem : la fonction de lec- 
ture assure I'extraction d'un attribut 6, 20 ou d'un 
composant 21 d'un attribut opaque 20 de I'annuaire 

45 4. Si le composant demande est recherche par son 
identifiant d'objets, la fonction de lecture n'a pas a 
charger la description compilee : la table 23 inte- 
gree de Pattribut est suffisante. A I'appel de la fonc- 
tion de lecture, sont precises la version, la classe, 

50 I'identifiant ou le nom de I'element, I'occurrence en 
cas de liste, la longueur utile dans le cas de types 
bit ou secret, le type de I'element, 

une fonction de suppression RemElem : la fonction 
55 de suppression effectue la suppression de la valeur 
d'un attribut 6,20 ou d'un composant 21 d'un attribut 
opaque 20, d'une occurrence d'une liste de compo- 
sants dans un objet. A I'appel de la fonction de sup- 
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pression, sont precises la version, la classe, I'iden- 
tifiant ou le nom de I'element, I'occurrence en cas 
de liste, la longueur utile dans le cas de types bit ou 
secret, le type de codage de I'element. 

une fonction de verification CheckObj : la fonction 
de verification verifie les attributs 6,20 d'un objet et 
les composants 21 d'un attribut opaque 20 avant 
validation d'une creation ou d'une modification. La 
fonction de verification permet le controle de pre- 
sence obligatoire des attributs/composants. Elle 
peut etre appelee par une entite 8, mais elle peut 
egalement etre mise en oeuvre systematiquement. 
A I'appel de la fonction de verification, sont precises 
la version, la classe, I'identifiant ou le nom de I'ele- 
ment, I'occurrence en cas de liste, la longueur utile 
dans le cas de types bit ou secret, le type de codage 
de I'element. 

[0078] L'entite 8 appelle une fonction 14 de gestion 
en placant les parametres necessaires a ladite fonction 
1 4 dans la structure de communication 1 7. La structure 
de communication 17 se presente sous la forme d'une 
succession de tous les parametres necessaires a toutes 
les fonctions 14 de gestion. La fonction 14 de gestion 
appelee recupere dans la structure 17 de communica- 
tion les valeurs de parametres qui I'interessent. 
[0079] Les fonctions 1 4 de gestion renvoient un code 
retour indiquant si la fonction a ete correctement effec- 
tuee, si une erreur est intervenue, si les parametres 
d'appel sont corrects, si la description compilee a ete 
retrouvee, si I'objet existe ... 

[0080] Les fonctions 14 de gestion sont concues de 
maniere a suivre les regies de gestion de versions enon- 
cees plus haut. 

[0081] Les fonctions. 14 de gestion permettent de lire 
une suite d'attributs/ composants sans solliciter I'an- 
nuaire 4. 

[0082] Les fonctions 1 4 de gestion assurent le chiffre- 
ment/dechiffrement et la signature des composants 21 
contenus dans I'attribut opaque 20. Les fonctions de 
gestion communiquent avec le module de securite 19 
pour effectuer les operations de securite (signature, 
chiffrement, ...) requises dans une description d'item 25 
et/ou dans I'en-tete 22 d'un attribut opaque. II est a noter 
que le module de securite 19 est independant : l'entite 
8 peut faire appel directement au module de securite 
comme le montre la figure 1 . 

[0083] Le systeme 1 decrit fonctionne de la maniere 

suivante : 

[0084] Lorsque l'entite 8 souhaite creer un objet dans 
I'annuaire 4, l'entite 8 commence par appeler la fonction 
de gestion 14 d'initialisation : l'entite 8 introduit les pa- 
rametres d'appel suffisants dans la structure de com- 
munication 17. La fonction 14 d'initialisation extrait de 
ladite structure les parametres qui lui sont necessaires, 
charge la description 25 compilee correspondante dans 
la memoire tampon 18 et cree la structure de depart 



d'objet souhaitee en definissant des valeurs par defaut. 
La structure est enregistree dans la memoire tampon 
18. La structure creee, la fonction 14 d'initialisation in- 
dique a l'entite 8 que la structure est prete a recevoir 

5 des attributs standards 6 ou des composants 21 en ren- 
voyant un code retour adapte dans la structure de com- 
munication 17. Comme indique plus haut, divers codes 
retour sont susceptibles d'etre transmis a l'entite 8 pour 
lui indiquer I'etat de fonctionnement. Lorsque l'entite de- 

10 tecte le code retour indiquant que la structure de depart 
a ete creee, l'entite 8 appelle alors la fonction 1 4 de ges- 
tion de rangement: elle transmet a la structure de com- 
munication les caracteristiques des attributs standards 
6 ou des composants 21 qu'elle souhaite introduce dans 

75 I'attribut opaque 20 concerne. La fonction 1 4 de range- 
ment les recupere et remplit la structure d'objets prece- 
demment creee dans la memoire tampon 18 en s'ap- 
puyant sur la description compilee chargee. La fonction 
1 4 de rangement peut egalement faire appel au module 

20 19 de securite en cas de signature ou de chiffrement 
des informations contenues dans I'objet concerne. Lors- 
que I'objet est pret a etre transfere dans I'annuaire 4, 
l'entite 8 a le choix entre valider la creation ou la verifier 
sachant qu'en validant, l'operation de verification est 

25 egalement realisee. La verification avant validation per- 
met d'obtenir precisement toutes les erreurs realisees. 
L'operation de verification est effectuee par la fonction 
de gestion de verification. Lorsque l'entite 8 valide la 
creation, la fonction 15 d'acces transfere I'objet crSe et 

30 renseigne dans I'annuaire 4. 

[0085] Lorsque l'entite 8 souhaite modifier un objet 
dans I'annuaire 4, l'entite 8 commence par appeler la 
fonction 15 d'acces. La fonction 15 d'acces retrouve 
I'objet dans I'annuaire 4 et en transfere une copie dans 

35 la memoire tampon 18. La fonction 15 d'acces indique 
par code retour a l'entite 8 que I'objet a ete correctement 
transfere dans la memoire tampon 18. L'entite 8 appelle 
alors la fonction 1 4 de gestion de rangement : elle trans- 
met a la structure de communication 17 les caracteris- 

40 tiques modifiees de I'attribut standard 6 ou du compo- 
sant 21 de I'attribut opaque 20 concerne. La fonction 1 4 
de rangement extrait les parametres qui lui sont neces- 
saires de la structure de communication 1 7 et charge la 
description compilee correspondante dans la memoire 

45 tampon 18. La fonction 1 4 de rangement modifie I'objet 
en question enregistre dans la memoire tampon 18 par 
la fonction d'acces 15, comme indique par les parame- 
tres de la structure de communication transmis par l'en- 
tite 8 et conformement a la description compilee. La 

50 fonction de rangement peut egalement faire appel au 
module de securite 19 en cas de signature ou de chif- 
frement des informations contenues dans I'objet concer- 
ne. Lorsque I'objet est pret a etre transfere dans I'an- 
nuaire 4, l'entite 8 a le choix entre valider la creation ou 

55 |a verifier sachant qu'en validant, I'operation de verifica- 
tion est egalement realisee. La verification avant valida- 
tion permet d'obtenir precisement toutes les erreurs rea- 
lisees. L'operation de verification est effectuee par la 
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fonction de gestion de verification. Lorsque I'entite 8 va- 
lide la modification, la fonction 1 5 d'acces transfere I'ob- 
jet modifie de la memoire tampon 18 dans I'annuaire 4. 
[0086] Lorsque I'entite 8 souhaite supprimer un attri- 
but 6, 20 ou un composant 21 de I'annuaire 4, I'entite 8 
commence par appeler la fonction 15 d'acces. La fonc- 
tion 15 d'acces retrouve I'objet dans I'annuaire 4 et en 
transfere une copie dans la memoire tampon 18. La 
fonction 15 d'acces indique par code retour a I'entite 8 
que I'objet a ete correctement transfere dans la memoire 
tampon 1 8. L'entite 8 appelle alors la fonction 1 4 de ges- 
tion de suppression : elle transmet a la structure de 
communication les caracteristiques de I'attribut stan- 
dard 6 ou du composant 21 a supprimer de I'attribut opa- 
que 20 concerne. La fonction 14 de suppression extrait 
les parametres qui lui sont necessaires de la structure 
de communication 17 et charge la description compilee 
correspondante dans la memoire tampon 18. La fonc- 
tion 14 de suppression supprime le composant 21 ou 
I'attribut 6,20 en question enregistre dans la memoire 
tampon 18 par la fonction d'acces 15, comme indique 
par les parametres de la structure de communication 
transmis par I'entite 8 et conformement a la description 
compilee. La fonction 15 d'acces supprime I'attribut 6, 
20 ou le composant 21 indique dans la memoire tampon 
18 dans I'annuaire 4. 

[0087] Lorsque I'entite 8 souhaite lire un objet dans 
I'annuaire 4, I'entite 8 commence par appeler la fonction 
1 5 d'acces. La fonction 1 5 d'acces retrouve I'objet dans 
I'annuaire 4 et en transfere une copie dans la memoire 
tampon 18. La fonction d'acces indique par code retour 
a I'entite' 8 que I'objet a ete correctement transfere dans 
la memoire tampon 18. L'entite 8 appelle alors la fonc- 
tion de gestion 14 de lecture. Si les parametres fournis 
par l'entite 8 sont suffisants et en particulier si le nom 
interne de I'attribut standard ou du composant a ete don- 
ne, la fonction de lecture n'a pas besoin de charger la 
description compilee. Dans le cas contraire, la descrip- 
tion compilee est chargee de maniere a obtenir la cor- 
respondence entre le nom interne et I'identifiant. La 
fonction 1 4 de lecture verifie eventuellement si l'entite 8 
a le droit de lire les informations concernees en faisant 
appel au module de securite 1 9. Elle dechiff re eventuel- 
lement lesdites informations et verifie leur integrite. Elle 
retrouve les informations souhaitees de I'objet en par- 
courant I'ensemble 24 des valeurs a I'aide de I'identifiant 
ou libelle et de la longueur utile. Elle place lesdites in- 
formations dans la structure de communication 17. L'en- 
tite 8 n'a plus qu'a lire les informations requises dans la 
structure de communication 17. 
[0088] Selon un developpement de I'invention, les 
versions de description anterieures a une version utili- 
sed a un instant t sont archivees dans un repertoire 
separe . Les versions de description anterieures peu- 
vent etre archivees par exemple en ajoutant au nom un 
suffixe representant le numero de version. 
[0089] La presente invention concerne done un pro- 
cede de gestion de I'annuaire 4 ou equivalent compor- 



tant les objets 5 caracterises par les attributs standards 
6, I'annuaire 4 etant apte a etre interroge par l'entite 8, 
caracterise en ce qu'il consiste a caracteriser les objets 
5 par les attributs specifiques 20 dits attributs opaques 
5 20, presentant la meme structure externe que les attri- 
buts standards 6 et dont la structure interne permet de 
definir et administrer les composants 21 de maniere in- 
dependante a I'annuaire 4. 

[0090] Le procede selon I'invention consiste a definir 
10 et administrer les composants 21 au moyen de I'interfa- 
ce de programmation au niveau applicatif API 13 entre 
I'annuaire 4 et I'entite 8. 

[0091] Le procede consiste a definir la structure inter- 
ne de I'attribut opaque en trois parties : 

15 

I'en-tete 22 delivrant des informations generales sur 
I'attribut opaque 20 ; 

la table 23 de caracteristiques des composants 21 ; 
I'ensemble 24 de valeurs des composants 21 indi- 
20 ques dans la table 23. 

[0092] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations de 
securite assurant Pintegrite, I'origine et/ou la confidenti- 
25 alite des composants 21 contenus dans I'attribut 20. 
[0093] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations per- 
mettant la gestion de differentes versions du contenu de 
I'attribut 20. 

30 [0094] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 le type de codage de 
chaque composant 21 contenu dans ledit attribut 20. 
[0095] Le procede consiste a lire ou mettre a jour, a 
savoircreer, modifier, lireou supprimer, un attribut stan- 
35 dard 6, un attribut opaque ou un composant 21 dans un 
attribut opaque 20 de maniere independante a I'annuai- 
re 4 au moyen des fonctions de gestion 1 4 des attributs 
opaques 20 appelees par I'entite 8. 
[0096] Les fonctions 14 de gestion s'appuient sur la 
40 description 25 des attributs 6,20 pour effectuer leur mise 
a jour, ainsi que leur lecture si l'entite 8 n'a pas fourni 
les informations suffisantes pour acceder directement a 
I'attribut concerne dans I'annuaire 4. 
[0097] Le procede consiste a compiler la description 
45 25 a I'aide d'un compilateur 1 0. 

[0098] Le procede consiste a integrerdans la descrip- 
tion 25 des informations de securite assurant I'integrite, 
I'origine et/ou la confidentiality des composants 21 con- 
tenus dans I'attribut 20. 
so [0099] Le procede consiste, au moyen des fonctions 
1 5 d'acces a I'annuaire 4, a extraire, introduire, modifier 
ou supprimer des attributs 6,20 dans I'annuaire 4 con- 
formement aux operations effectuees par les fonctions 
14 de gestion. 

55 [0100] La presente invention porte egalement sur le 
systeme informatique permettant la mise en oeuvre du- 
dit procede. 

[0101] La presente invention se rapporte a un syste- 
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me informatique comprenant au moins une machine 2 
munie de I'annuaire 4 ou equivalent susceptible d'etre 
interroge par Pentite 8, caracterise en ce qu'il comprend 
1'interface de programmation au niveau applicatif AP1 1 3 
entre I'annuaire 4 et I'entite 8 comprenant les fonctions 
15 d'acces a I'annuaire 4 et les fonctions 14 de gestion 
d'attributs standards 6 et/ou d'attributs opaques 20. 
[0102] L'entite 8 communique avec I'interface API 13 
au travers de la structure de communication 1 7 enregis- 
tree dans les moyens de memorisation 16. 
[0103] Le systeme comprend les moyens 11 de stoc- 
kage des fichiers source 12, le compilateur 10 desdits 
fichiers 12. 

ANNEXES 

Exemples de fichier source 12. 

[0104] / description 25 de I'item BASE de la classe 
d'objets Personne 

CLASS=PERSONNE 
ITEM=BASE 
VERSION=001 
LANGUAGES=EN,FR 

/ description 21 des attributs standards 6 de I'item 
BASE 

ATT=CNAME 
OID=0001 

XNM=commonName 
HID=N 

LBL=EN="User common name" 

LBL=FR="ident X500 de I'usager" 

TYP=TEXT 

MDT=Y 

RNG=64 

SZF=24 

CAS=FREE 

ATT=SURNAME 
OID=0002 
XNM=surname 
HID=N 

LBL=EN="User surname" 

LBL=FR="Patronyme X500 de I'usager" 

TYP=TEXT 

MDT=Y 

RNG=32 

SZF=16 

CAS=LOW 

ATT=TELE PHONE 
OID=0003 

XNM= telephoneNumber 
HID=N 

LBL=EN="User telephone" 



LBL=FR="Telephone usager" 
MDT=N 
RNG=16 
SZF=16 
5 CAS=UP 

/ description 25 d'un item attribut opaque SECITEM 20 
de la classe d'objets PERSON 
/ description des composants de I'attribut opaque, dans 
10 I'item SECITEM 

CLASS=PERSON 
ITEM=SECITEM 
VERSION=001 
IS LANGUAGES=EN,FR 

/ description 25 des attributs opaques 20 de I'item 
/ definition de la liste des ressources accordees 

20 ATT=LISTRAL 
OID=100 

LBL=EN="Resource allocated list" 
LBL=FR="Liste des ressources allouees" 
TYP=LIST 
25 PRS=PCM 
RNG=50O 

/classe des ressources de la liste 

30 ATT=OBJECTCLASS 
OID=101 

LBL=EN="Resource class" 
LBL=FR="Classe de la ressource" 
TYP=TEXT 
35 RNG=48 
CAS=UP 

/nom de la ressource 

40 ATT=OBJECTID 
OID=102 

LBL=EN="Resource name" 
LBL=FR="Nom de la ressouce" 
TYP=TEXT 
45 MDT=N 
SZF=48 
RNG=96 
CAS=UP 

so I fin description de la liste (d'une occurrence liste) 

ATT=ENDOFLIST 
OID=100 
HID=Y 
55 TYP=END 

/ exemple de description des droits d'acces aux noeuds 
et objets 
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/ droit sur le niveau noeud 

ATT=NODERGT 

O!D=102 

HID=N 

LBL=EN="Rights on node" 

LBL=FR="Droits sur le noeud" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CHILDGRGT 

O!D=103 

HID=N 

LBL=EN="General rights on attached objects" 

LBL=FR="Droits generaux sur les objets ratta- 

chees" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CLASSRGT 

OID=104 

HID=N 

LBL=EN="Specific rights on attached objects" 

LBL=FR="Droits specifiques sur les objets ratta- 

chees" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 



un en-tete (22) delivrant des informations ge- 
nerates sur I'attribut opaque (20); 
une table (23) de caracteristiques des compo- 
sants (21) ; 

un ensemble (24) de valeurs des composants 
(21) indiques dans la table (23). 

Procede selon I'une des revendications 1 a 3, ca- 
racterise en ce qu'il consiste a integrer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations de securite assurant I'integrite, I'origine et/ 
ou la confidentialite des composants (21) contenus 
dans I'attribut (20). 

Procede selon I'une des revendications 1 a 4, ca- 
racterise en ce qu'il consiste a integrer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations permettant la gestion de differentes ver- 
sions du contenu de I'attribut (20). 

Procede selon I'une des revendications 1 a 5, ca- 
racterise en ce qu'il consiste a integrer dans la 
structure interne de I'attribut opaque (20) le type de 
codage de chaque composant (21) contenu dans 
ledit attribut (20). 

Procede selon I'une des revendications 1 a 6, ca- 
racterise en ce qu'il consiste a lire ou mettre a jour, 
a savoir creer, modifier, lire ou supprimer, un attribut 
standard (6), un attribut opaque ou un composant 
(21) dans un attribut opaque (20) de maniere ind6- 
pendante a la base (4) au moyen de fonctions de 
gestion (14) des attributs opaques (20) appelees 
par I'entite (8). 



Revendications 

1. Procede de gestion d'une base de donnees (4) ou 
annuaire ou equivalent comportant des objets (5) 
caracterises par des attributs standards (6), la base 
(4) etant apte a etre interrogee par une application, 
un utilisateur ou autre appele entite (8), caracterise 
en ce qu'il consiste a caracteriser les objets (5) par 
des attributs specifiques (20) dits attributs opaques 

(20) , presentant la meme structure externe que les 
attributs standards (6) et dont la structure interne 
permet de definir et administrer des composants 

(21) de maniere independante a la base (4). 

2. Procede selon la revendication 1 , caracterise en ce 
qu'il consiste a definir et administrer les compo- 
sants (21) au moyen d'une interface de program- 
mation au niveau applicatif API (13) entre la base 
(4) et I'entite (8). 

3. Procede selon I'une des revendications 1 ou 2, ca- 
racterise en ce qu'il consiste a definir la structure 
interne de I'attribut opaque en trois parties : 



8. Procede selon la revendication 7, caracterise en ce 
que les fonctions (14) de gestion s'appuient sur une 
description (25) des attributs (6,20) pour effectuer 
leur mise a jour, ainsi que leur lecture si I'entite (8) 
n'a pas fourni les informations suffisantes pour ac- 
ceder directement a I'attribut conceme dans la base 
(4). 

9. Procede selon la revendication 8, caracterise en ce 
qu'il consiste a compiler la description (25) a I'aide 
d'un compilateur (10). 

10. Procede selon I'une des revendications 8 ou 9, ca- 
racterise en ce qu'il consiste a integrer dans la des- 
cription (25) des informations de securite assurant 
I'integrite, I'origine et/ou la confidentialite des com- 

s (21) contenus dans I'attribut (20). 



11. Procede selon la revendication 7, caracterise en ce 
qu'il consiste, au moyen de fonctions (15) d'acces 
a la base (4), a extraire, introduire, modifier ou sup- 
primer des attributs (6,20) dans la base (4) confor- 
mement aux operations effectuees par les fonctions 
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(14) de gestion. 

12. Systeme informatique comprenant au moins une 
machine (2) munie d'une base de donnees (4) ou 
annuaire ou equivalent susceptible d'etre interro- s 
gee par une application, un utilisateurou autre, ap- 
pele entite (8), caracterise en ce qu'il comprend une 
interface de programmation au niveau applicatif 
API (13) entre la base (4) et Pentite (8) comprenant 
des fonctions (1 5) d'acces a la base (4) et des tone- 10 
tions (1 4) de gestion d'attributs standards (6) et/ou 
d'attributs opaques (20). 

13. Systeme selon la revendication 12, caracterise en 

ce que I'entite (8) communique avec I'interface API is 
(13) au travers d'une structure de communication 
(17) enregistree dans des moyens de memorisation 
(16). 

14. Systeme selon Tune des revendications 12 ou 13, 20 
caracterise en ce qu'il comprend des moyens (11) 

de stockage de fichiers source (12), un compilateur 
(10) desdits fichiers (12). 

15. Systeme informatique permettant la mise en oeuvre 25 
du procede selon Tune des revendications 1 a 11. 
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En-tete 

Version ; 

Longueur en octets ; 
Informations de securite* ; 
Date de derniere mise a jour ; ... 



Table 
I Identifiant; 
I Type de codage ; 

l Informations complementaires de codage ; 
l Longueur utile ; ... 
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